• I thought about documentation and added the doc-change-required label to this PR if updates are required.
• I have considered running ./gradlew acceptanceTestNonMainnet locally if my PR affects non-mainnet modules.
• I thought about the changelog and included a changelog update if required.

To accurately gauge the impact of this PR on Besu's performance, particularly regarding block processing, the most effective approach is to deploy it on a dedicated environment with real data. It's preferable to use an environment with many deposits, and then profile the node to observe any impact on performance. In the meantime, I've identified two pertinent methods to assess performance by conducting microbenchmarking with JMH

• DepositDecoder.decodeFromLog
• BodyValidation.depositRoots

During block processing, both methods are invoked, with DepositDecoder.decodeFromLog being called iteratively within a loop that depends on the quantity of receipts and logs per receipt present in the block

Block processing

AbstractEngineNewPayload.syncResponse
        BodyValidation.depositsRoot
	MergeCoodinator.rememberBlock
		MergeCoodinator.validateBlock
			MainnetBlockValidator.validateAndProcessBlock
				MainnetBlockValidator.validateAndProcessBlock
					MainnetBlockBodyValidator.validateBodyLight
						AllowedDeposits.validateDeposits
							DepositDecoder.decodeFromLog (called several times)
						AllowedDeposits.validateDepositsRoot
							BodyValidation.depositsRoot	

Block creation

AbstractBlockCreator.createBlock
	BodyValidation.depositsRoot
	DepositDecoder.decodeFromLog (called several times)

The microbenchmarking of both methods (Keccak256 was added to enable a comparison point)

Benchmark                                     Mode  Cnt       Score      Error  Units
DepositDecoder.decodeFromLogBenchmark         avgt  100   12261.105 ±   80.786  ns/op
DepositDecoder.keccakk256Benchmark            avgt  100     306.937 ±    0.377  ns/op
BodyValidation.depositsRootBenchmark          avgt  100  238915.938 ± 4451.589  ns/op

If I'm not wrong, BodyValidation.depositRoots is called twice during block processing, and it takes 1/4 ms to execute, I think we can save one execution but even with both executions, the overhead is acceptable.

DepositDecoder.decodeFromLog overhead will depends on the number of receipts per block and the number of logs per receipt. If there're for example 1000 logs to process, this represents 13 ms overhead for block processing and block creation.

I started also a node on mainnet with PR to test against main on current fork (previous commit of this PR 795b7c4), I don't see any performance regression on block processing or FCU

From what I gathered, I don't see a blocker to merge this PR in termes of performance

I've started a regression test, fresh X_CHECKPOINT sync of 3 BONSAI nodes: sepolia, goerli, mainnet.

I've started a regression test, fresh X_CHECKPOINT sync of 3 BONSAI nodes: sepolia, goerli, mainnet.

This has passed regression: all nodes got in sync and have stayed in sync. No errors in the logs.

Reran some regression tests (deposits disabled) on latest changes with a local interop and sepolia sync ✅
Think this is ready to merge if @jframe is happy with latest changes.

Reran some regression tests (deposits disabled) on latest changes with a local interop and sepolia sync ✅ Think this is ready to merge if @jframe is happy with latest changes.

Looks fine to me

Thanks @jframe. I will hold off merging until we are sure main branch is clear: there are some issues on main found during the 23.4.2 soak.